home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
FishMarket 1.0
/
FishMarket v1.0.iso
/
fishies
/
076-100
/
disk_084
/
audiotools
/
test.the.examples
< prev
next >
Wrap
Text File
|
1992-05-06
|
3KB
|
70 lines
A FEW MORE DETAILS
------------------
Starting The Program:
When you have compiled the routines using the instructions in COMPILING,
you have a program that must be started from a CLI. Assuming you have
compiled it from RAM:
1> run ram:audiotools
I have deliberately defined the DEBUG variable so that you can see
what the program is doing internally. Of particular interest is the
multitasking that is visible once the notes begin to play. That is,
as the notes are being retrieved from the note queue, your task is
busy freeing any I/O request blocks that are returned from the
audio device. Thus the device and your task are both running
at the same time.
About Errors:
-------------
The error value, no matter what is created in an internal routine, is
converted to a zero or nonzero error value, depending on whether there is
no error (0), or some error (nonzero, usually set to -1). You may have
some other preference about passing back the actual error value. That
is up to you.
About the ExtIO data structure:
-------------------------------
For the next release, it will most likely remain identical to
IOAudio. I've been thinking about how to implement the message
and priority features I specified in the article and can state
my plans for this feature:
Continue to bury the details of message packet creation
in my own routines. Instead of "Message", this field
should be "MsgPort".
a. MY routines set up the audio device
communications and IOAudio;
b. audio device tells ME when it
starts to play a queued note;
c. MY routine allocates memory for a message block,
sends it to the user's MsgPort with the priority
field value as the identifier when this note
begins to play;
d. User replies to the message, and MY routines free
the memory the message used. The user need only
know how to retrieve and reply to messages and
needs no knowhow about proper setup of audio device
or about memory allocation for messages. Consistent
with other routines in this audio library.
(Going one step further, InitAudio() could return to
the user the address of the message port that he'd
use to retrieve messages about notes beginning, then
FinishAudio() could free that port. Small change but
may help casual user.)
Yes, that's what we'll do. Have InitAudio() return
the address of a newly created MsgPort, then the user
will not have to specify a message, or a MsgPort address
in the call. The value of the priority field will be
sufficient to say whether to send a message or not!